This invention relates generally to handling of memory address reassignment within a millicode capable processor and more particularly to dynamic address translation with use of a translation lookaside buffer (TLB).
Dynamic address translation (DAT) is a process defined in a computer architecture that relates to a mapping process. The process provides for converting a logical (i.e., virtual) address used in software to the actual absolute (i.e., physical) address used in a hardware memory subsystem of the computer architecture. That is, in some computer architectures, instructions are provided to software, in particular operating systems, to change architectural states for a specific number of processes (e.g. updating of control registers, or invalidation of translation tables or access keys). Note that for convention, the terminology “architectural states,” “translation control information,” “translation information” and other similar terms make reference to or generally include page tables, control registers, TLB entries, and other architected or non-architected translation control state(s).
These changes in turn can affect dynamic address translations (DAT) results. It is important that architectural states can be changed quickly in a processor. On the other hand, since the update process to architectural states can be complicated, due to the nature of direct hardware involvement, these instructions are often times implemented in internal code of the processor, such as by millicode.
A typical processor includes a branch prediction unit that can fetch ahead instructions that are currently executing. These fetches in turns can miss a translation lookaside buffer (TLB) and ultimately require address translation. A complication arises during the execution of updates to the control register by use of millicode process. That is, while the millicode is updating the control registers, these “fetch ahead” translation misses can be in progress, or being initiated due to the asynchronous nature of branch prediction and instruction fetching. This often times can result in an illegal translation stored into a translation lookaside buffer of the processor, or generation of illegal states within a hardware translation engine.
For convention, a Translation Lookaside Buffer (TLB) is a fast speed memory structure in a processor. The TLB is used by memory management hardware to improve the speed of virtual address translation. Generally, the TLB has a fixed number of slots containing page table entries, which map virtual addresses onto physical addresses. It is typically a content-addressable memory (CAM), wherein a search key is the virtual address and a search result is a physical address. If a requested address is present in the TLB, the CAM search yields a match very quickly, after which the physical address can be used to access memory. The TLB can also be implemented in a set associative manner. If the requested address is not in the TLB, the translation proceeds using a page table, which is slower to access. Furthermore, translation takes significantly longer if the translation tables are swapped out into secondary storage.
The TLB references physical memory addresses in its table. The TLB may reside between the processor and the processor cache or between the processor cache and primary storage memory. This depends on whether the cache uses physical or virtual addressing. If the cache is virtually addressed, requests are sent directly from the processor to the cache, which then accesses the TLB as necessary. If the cache is physically addressed, the processor does a TLB lookup on every memory operation, and the resulting physical address is sent to the cache.
Two schemes for handling TLB misses are commonly found in modern architectures. Those of hardware management and those of software management.
In typical prior art processors using hardware TLB management, the processor examines page tables to see if there is a valid page table entry for the specified virtual address. If an entry exists, it is brought into the TLB and the TLB access is retried: this time the access will hit, and the program can proceed normally. If the processor finds no valid entry for the virtual address in the page tables, it raises a page fault exception, which the operating system must handle. Handling page faults usually involves bringing the requested data into physical memory, setting up a page table entry to map the faulting virtual address to the correct physical address, and restarting the program.
Typically, with software-managed TLBs, a TLB miss generates a “TLB miss” exception, and the operating system must examine the page tables and perform the translation in software. The operating system then loads the translation into the TLB and restarts the program from the instruction that caused the TLB miss. As with hardware TLB management, if the operating system does not find a valid translation in the page tables, a page fault has occurred, and the operating system must handle it accordingly.
Serializing around updates of architectural states that may influence translation lookaside buffer data is important to ensure correctness and to prevent illegal data from being stored in the translation lookaside buffer. Typically, existing methods for serializing used inside millicode involve a complex series of drain instructions and branch prediction restrictions to prevent the illegal data from being stored in the translation lookaside buffer. However, these methods can sometimes be ineffective if the processor pipeline is long, and/or if the processor is executing out of order. Solutions usually involve disabling of global branch prediction which possibly leads to unnecessary performance degrades.
What are needed are techniques to enable millicode to be effective in ensuring that no illegal results can be obtained and installed during architectural state updates. Preferably, the techniques take advantage of hardware protections to increase effectiveness.